The use of various forms of processor-based platforms has proliferated in recent years. For example, the use of processor-based personal communication and data processing platforms, often referred to as smartphones, has sharply increased in the last few years and is expected to continue for the foreseeable future. For example, in addition to their use in providing cellular telephone communication services, smartphones are commonly used for providing data communications, data processing, viewing and/or creating streaming media, gaming and entertainment, etc. The applications operable to provide the foregoing functionality range from applications that utilize relatively little processing power and other resources (e.g., thin clients and simple web browser applications) to applications that require significant processing power and/or resources (e.g., virtual reality (VR) and augmented reality (AR) applications, complex gaming and graphics applications, etc.).
Processing power and resources in general are limited in many current processor-based platforms, particularly mobile and battery powered processor-based platforms. For example, hardware resources, such as a central processing unit (CPU), main memory, and input/output (I/O) devices, provide appreciably limited processing, availability, and functionality in smartphone implementations. When a number of applications are run concurrently by the processor-based platform, the applications compete for the processor-based platform hardware resources. Accordingly, the performance of a processor-based system, particularly a processor-based system such as a smartphone having limited hardware resources, is generally degraded by the concurrent execution of applications. For example, multifunction operation provided by a typical smartphone executing multiple applications concurrently can result in perceptible latencies experienced by the applications.
Nevertheless, smartphones (e.g., mobile devices based upon the ANDROID operating system) and other mobile devices providing general purpose computing functionality (e.g., personal digital assistants, tablet devices, etc.) continue to experience worldwide popularity and their use has been so widely adopted as to become nearly ubiquitous. Correspondingly, the demand for applications has grown, with the types of applications available for use on these processor-based systems and their functionality and complexity also ever increasing. In particular, as the games and application market grows, the demand for low latency applications (e.g., VR, AR, audio, vehicle control, etc.) increases. The processor-based platforms and associated operating systems provided by many devices, such as smartphones and other mobile devices providing general purpose computing functionality, are not designed for low latency application execution by default. Accordingly, the user experience is often significantly impacted (e.g., the user perceives stutter in audio playback, perceptibly missing video frames, delay in data update, etc.) when such applications, which require a very strict time constraints, execute in a non-optimized operating systems.
Although some attempts at providing improvement with respect to low latency performance have been made, the existing proffered low latency techniques have heretofore been less than optimum. For example, Kernel space low latency techniques have included trimming system overhead down (e.g., remove unused modules in the Linux Kernel, such as to reduce driver load time) or implementing generic low latency Linux Kernels (e.g., using the Linux RT-patch to change the generic Linux Kernel to have a certain “real-time” ability), as may be implemented with respect to the ANDROID operating system of a smartphone. Further, a number of user space low latency techniques have been provided. For example, user space low latency techniques have included techniques to trim system overhead down (e.g., pre-disable unneeded services in the ANDROID operating system, such as to reduce background noise), various techniques for minimizing the size of the application code (e.g., using the “−O3” compile option (GNU compiler toolchain), such as to provide execution speed optimized instructions and compilation options as may lessen start-up times), or the use of well-structured coding techniques (e.g., using locking mechanisms carefully, use lesser delay/sleep, do not block callbacks, etc.).
Such low latency optimization techniques have generally been used with respect to embedded system programming and are typically applied statically to the system, applied before the application or system runs, and are not resources oriented (i.e., are not adapted to perform optimization to specific hardware or software modules). For example, the aforementioned generic low latency Linux Kernels are not optimized for execution of any particular application and often provide no significant effect when an application needs an actual low latency environment. Moreover, when such a low latency Linux Kernel is implemented in a processor-based system the low latency Kernel statically exists in that system (i.e., it is present and operating) and does not provide for dynamically enabling or disabling the low latency functionality (e.g., on an application by application basis, such as where the low latency implementation of the Kernel is not advantageous or desired with respect to one or more application). For example, the Linux RT-Patch itself does not provide dynamic features, and instead the real time options are only configurable via a configuration list (e.g., generated by text-UI based menu options selection tools) before compilation and thus none of these options are selectable after the Linux Kernel is running. With respect to the above mentioned system trim down technique, unneeded features (e.g., driver modules) are pre-removed and thus the technique is statically applied to the system. Even where seldom used features are compiled to loadable/unloadable modules to reduce the size of the resultant system, once the features of such modules are needed the loading/unloading of the modules will increase execution time.
Similarly, the user space low latency techniques are not optimized with respect to any particular application, may be statically applied, and, depending upon the resources utilized by an application, may or may not result in any significant effect on the latency experienced by the application. For example, improving executing performance by using optimized compilation options (e.g., using the “−O3” compile option of GNU compiler toolchain) is applicable during compile time and is unable to revert during runtime. Moreover, the existing user space low latency techniques are not tightly coupled with an existing Kernel space low latency technique, and thus do not provide for low latency optimization for the operating system and application combination, but rather attempt to individually and independently address latency aspects of an associated one of the operating system and application. For example, command lines able to start/stop system services may be available to developers, but these command line tools are normally not accessible by application developers. Moreover, the existing user space low latency techniques focus on application related tasks, but not the whole data path. Furthermore, the existing user space low latency techniques do not have direct access to the processor-based system hardware or information thereof, and instead interface through a hardware abstraction layer (HAL) that prevents an understanding of the particular hardware utilized by applications.